Basic Concepts in Bridge Commander

This section describes some of the basic concepts in Bridge Commander -- basically, the way the world "works". Other documents provide much more detail on the concepts presented here, but this is a good starting point for learning about the internals of Bridge Commander.


Scripts

Python scripts control a lot of what happens in Bridge Commander. These scripts are located in the "scripts" subdirectory in the Bridge Commander directory. There are a number of subdirectories in here -- some of the more important ones are:

You can modify these scripts, or create new ones, to change the way Bridge Commander behaves.


Game, Episode, Mission

Bridge Commander "campaigns" are broken down into smaller pieces. A Game contains an entire campaign, and contains any number of episodes. An Episode is, in turn, composed of any number of Missions. Games, Episodes, and Missions are represented by scripts -- if you look in the Maelstrom subdirectory in scripts, you'll see a file called Maelstrom.py. This is the Game script for the single-player campaign in Bridge Commander. There are subdirectories for each episode of the game (each containing an Episode script), and subdirectories in each episode for missions (which contain Mission scripts).


Objects and Sets

Any sort of object in the world is considered to be of type ObjectClass (henceforth "objects") -- basically, it's the root class for most object types in the game world. Objects are usually contained in a "set" (class SetClass). A set is an environment in the game world -- for example, the bridge of the Dauntless, the region of space called "Biranu 2", or the "warp set", where ships go when they are warping. Sets can contain any number of objects -- however, the objects must be uniquely named (if they have a name). Objects can be moved to different sets at any time, but can only exist in one set at a time.

All of the sets in the game are accessed through the set manager. Objects in the game are accessed by getting them from their particular set, or by their unique ID.

A typical object and set list in Bridge Commander might look something like this:


More specific object types

Many classes inherit from ObjectClass, to implement more specific behavior for an object. In particular, objects in space and objects on a bridge follow separate inheritance paths. Below is a diagram showing some of the more important inheritance paths from ObjectClass.

Diagram


Controlling Mission Flow

A typical mission is not just a group of ships in sets. The mission must react to events in the game world and the player's actions, and trigger other things when appropriate. There are several mechanisms in Bridge Commander used to make things happen in the game world.

Missions will usually set up some of these mechanisms during initialization, and set up more during the course of a mission.

Mission example

Missions use a combination of the above mechanisms to control gameflow, and to make the mission "come alive." Here's an example of a very simple mission, and how it uses these mechanisms.

The mission involves having the player travel to Biranu 2. When the player arrives at Biranu 2, a dialogue sequence plays that talks about some strange readings coming from the planet. If the player comes close to the planet, four Cardassian Galors warp in and fight the player. When each Galor is damaged sufficiently, it warps out of the region. When all of the Galors have left, the player wins the mission.

To make this happen, you might implement the following pseudocode:


Ship Internals

Each ship in the game is made up of a number of different subsystems. Not every ship is required to have every subsystem, but most ships contain a large number of subsystems. These subsystems have attributes particular to them, and range from the very simple, like a hull, to complicated, like a phaser bank.

Types of subsystems:


Created on ... January 30, 2002